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Abstract 


The Path Computation Element (PCE) provides functions of path 
computation in support of traffic engineering (TE) in Multi-Protocol 
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 


When a Path Computation Client (PCC) requests a PCE for a route, it 
may be useful for the PCC to specify, as constraints to the path 
computation, abstract nodes, resources, and Shared Risk Link Groups 
(SRLGs) that are to be explicitly excluded from the computed route. 
Such constraints are termed "route exclusions". 


The PCE Communication Protocol (PCEP) is designed as a communication 
protocol between PCCs and PCEs. This document presents PCEP 


extensions for route exclusions. 
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Les 


1. 


Introduction 


The Path Computation Element (PCE) defined in [RFC4655] is an entity 
that is capable of computing a network path or route based on a 
network graph, and applying computational constraints. A Path 
Computation Client (PCC) may make requests to a PCE for paths to be 
computed. 


When a PCC requests a PCE for a route, it may be useful for the PCC 
to specify abstract nodes, resources, and Shared Risk Link Groups 
(SRLGs) that are to be explicitly excluded from the route. 


For example, disjoint paths for inter-domain Label Switched Paths 
(LSPs) may be computed by cooperation between PCEs, each of which 
computes segments of the paths across one domain. In order to 
achieve path computation for a secondary (backup) path, a PCE may act 
as a PCC to request another PCE for a route that must be 
node/link/SRLG disjoint from the primary (working) path. Another 
example is where a network operator wants a path to avoid specified 
nodes for administrative reasons, perhaps because the specified nodes 
will be out-of-service in the near future. 


[RFC4657] specifies generic requirements for a communication protocol 
between PCCs and PCEs. Generic constraints described in [RFC4657] 
include route exclusions for links, nodes, and SRLGs. That is, the 
requirement for support of route exclusions within the PCC-PCE 
communication protocol is already established. 


The PCE communication protocol (PCEP) is designed as a communication 
protocol between PCCs and PCEs and is defined in [RFC5440]. This 
document presents PCEP extensions to satisfy the requirements for 
route exclusions as described in Sections 5.1.4 and 5.1.16 of 
[RFC4657]. 


Note that MPLS-TE and GMPLS signaling extensions for communicating 
route exclusions between network nodes for specific Label Switched 
Paths (LSPs) are described in [RFC4874]. Route exclusions may be 
specified during provisioning requests for specific LSPs by setting 
the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in 
[RFC3812] to false (2). 


1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2. Protocol Procedures and Extensions 


This section describes the procedures adopted by a PCE handling a 
request for path computation with route exclusions received from a 
PCC, and defines how those exclusions are encoded. 


There are two types of route exclusion described in [RFC4874]. 


1. Exclusion of certain abstract nodes or resources from the whole 
path. This set of abstract nodes is referred to as the Exclude 
Route List. 


2. Exclusion of certain abstract nodes or resources between a 


Specific pair of abstract nodes present in an explicit path. Such 
specific exclusions are referred to as an Explicit Route 
Exclusion. 


This document defines protocol extensions to allow a PCC to specify 
both types of route exclusions to a PCE on a path computation 
request. 


A new PCEP object, the Exclude Route Object (XRO), is defined to 
convey the Exclude Route List. The existing Include Route Object 
(IRO) in PCEP [RFC5440] is modified by introducing a new IRO 
subobject, the Explicit Exclusion Route subobject (EXRS), to convey 
Explicit Route Exclusions. 


2.1. Exclude Route Object (XRO) 
2.1.1. Definition 


The XRO is OPTIONAL and MAY be carried within Path Computation 
Request (PCReq) and Path Computation Reply (PCRep) messages. 


When present in a PCReq message, the XRO provides a list of network 
resources that the PCE is requested to exclude from the path that it 
computes. Flags associated with each list member instruct the PCE as 
to whether the network resources must be excluded from the computed 
path, or whether the PCE should make best efforts to exclude the 
resources from the computed path. 


The XRO MAY be used on a PCRep message that carries the NO-PATH 
object (i.e., one that reports a path computation failure) to 
indicate the set of elements of the original XRO that prevented the 
PCE from finding a path. 


The XRO MAY also be used on a PCRep message for a successful path 
computation when the PCE wishes to provide a set of exclusions to be 


Oki, et al. Standards Track [Page 4] 


RFC 5521 Extensions to PCEP for Route Exclusions April 2009 


signaled during LSP setup using the extensions to Resource 
Reservation Protocol (RSVP)-TE [RFC4874]. 


The XRO Object-Class is 17. 
The XRO Object-Type is 1. 


0 I 2 3 

0 E23 A Oe P89 OT 2v 346507608 90 L238 A 6B Oe OL. 
$ototatatatatitotitititotatatatatatititotititotitititatatotototot 
| Reserved | Flags |E | 
TR MRTRR RETE MR]G-RRERE 
| | 


// (Subobjects) // 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4+-4-4+-4-4-4 
Figure 1: XRO Body Format 


Reserved: 16 bits - MUST be set to zero on transmission and SHOULD be 
ignored on receipt. 


Flags: 16 bits - The following flags are currently defined: 


F (Fail - 1 bit): when set, the requesting PCC requires the 
computation of a new path for an existing TE LSP that has failed. 
If the F bit is set, the path of the existing TE LSP MUST be 
provided in the PCReq message by means of a Record Route Object 
(RRO) defined in [RFC5440]. This allows the path computation to 
take into account the previous path and reserved resources to 
avoid double bandwidth booking should the Traffic Engineering 
Database (TED) have not yet been updated or the corresponding 
resources not be yet been released. This will usually be used in 
conjunction with the exclusion from the path computation of the 
failed resource that caused the LSP to fail. 


Subobjects: The XRO is made up of one or more subobject(s). An XRO 
with no subobjects MUST NOT be sent and SHOULD be ignored on receipt. 


In the following subobject definitions, a set of fields have 
consistent meaning as follows: 


X 
The X-bit indicates whether the exclusion is mandatory or desired. 
O indicates that the resource specified MUST be excluded from the 
path computed by the PCE. 1 indicates that the resource specified 
SHOULD be excluded from the path computed by the PCE, but MAY be 
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included subject to PCE policy and the absence of a viable path 
that meets the other constraints and excludes the resource. 


Type 
The type of the subobject. The following subobject types are 
defined. 
Type Subobject 
r— M M ——MBÓ qp——————————————————————————————— 
1 IPv4 prefix 
2 IPv6 prefix 
4 Unnumbered Interface ID 
32 Autonomous system number 
34 SRLG 
Length 


The length of the subobject including the Type and Length fields. 


Prefix Length 
Where present, this field can be used to indicate a set of 


addresses matching a prefix. If the subobject indicates a single 
address, the prefix length MUST be set to the full length of the 
address. 

Attribute 
The Attribute field indicates how the exclusion subobject is to be 
interpreted. 


0 Interface 
The subobject is to be interpreted as an interface or set of 
interfaces. All interfaces identified by the subobject are to be 
excluded from the computed path according to the setting of the 
X-bit. This value is valid only for subobject types 1, 2, and 3. 


1 Node 
The subobject is to be interpreted as a node or set of nodes. All 
nodes identified by the subobject are to be excluded from the 
computed path according to the setting of the X-bit. This value 
is valid only for subobject types 1, 2, 3, and 4. 


2 SRLG 
The subobject identifies an SRLG explicitly or indicates all of 
the SRLGs associated with the resource or resources identified by 
the subobject. Resources that share any SRLG with those 
identified are to be excluded from the computed path according to 
the setting of the X-bit. This value is valid for all subobjects. 
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Reserved 
Reserved fields within subobjects MUST be transmitted as zero and 
SHOULD be ignored on receipt. 


The subobjects are encoded as follows: 
IPv4 prefix Subobject 
0 1 2 3. 


0 dL: 4 526 T:8.9-0.1.2 3.4/5 6 4^8 90 L2.2-4 5-6 78.9 0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1 | 


|x| Type = Length | IPv4 address (4 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| IPv4 address (continued) | Prefix Length | Attribute | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 prefix Subobject 


0 1 2 3 
011-2 3: 45. 60 1:8 17950: 22:53: 54755: 76- 7,8. ON 0302: 3-4 5. 6:52:87 9 «0: X 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|x| Type = 2 | Length | IPv6 address (16 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv6 address (continued) | 


E A A E E A a A a MG 
| IPv6 address (continued) | 
a a a a e a a E S E E a a A 
| IPv6 address (continued) | 
AA a E E A A E A E MÀ tat 
| IPv6 address (continued) | Prefix Length | Attribute | 
D A a RHF rt atta tata E a a S E E E a A a GÀ — 
Unnumbered Interface ID Subobject 

0 1 2 3 


O0 L2 345-6 :8:9-0.1 2. 3.4.5.6 778.9 0 L2 3 4 5-6 .7:8»9-«0- 1 


V—R—R—R-R-R--—----R- LT ——---.-—.-.—4—4——---.- 4-44 
|x| Type = 3 | Length | Reserved | Attribute 
V—R—R—R-R-------R-R-———---.-—L-.-.-4——---.-— 4-4 


| TE Router ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Interface ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The TE Router ID and Interface ID fields are as defined in [RFC3477]. 
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Autonomous System Number Subobject 


0 1 2 3 

0 1:2: 3-4 56,158.90 12273: 5526 7-8.'9-0 T2 3-4 5 6 g9 0-1 
T ————————————— HHHH 
|x| Type = 4 | Length | 2-Octet AS Number 
————————M————————— —— Ga 


Note that as in other PCEP objects [RFC5440] and RSVP-TE objects 
[RFC3209], no support for 4-octet Autonomous System (AS) Numbers is 
provided. It is anticipated that, as 4-octet AS Numbers become more 
common, both PCEP and RSVP-TE will be updated in a consistent way to 
add this support. 


SRLG Subobject 
0 1 2 3 


0 12 345 6 7 8.9 0 1.2-.345 078 9 012 3.45 6 7 8.9 0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|x| Type=5 | Length | SRLG Id (4 bytes) 
—R—-———-- -——L--— -— — 4-4. MÀ MB 
| SRLG Id (continued) | Reserved | Attribute 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Attribute SHOULD be set to two (2) and SHOULD be ignored on 
receipt. 


2.1.2. Processing Rules 


A PCC builds an XRO to encode all of the resources that it wishes the 
PCE to exclude from the path that it is requested to compute. For 
each exclusion, the PCC clears the X-bit to indicate that the PCE is 
required to exclude the resources, or sets the X-bit to indicate that 
the PCC simply desires that the resources are excluded. For each 
exclusion, the PCC also sets the Attribute field to indicate how the 
PCE should interpret the contents of the exclusion subobject. 


When a PCE receives a PCReq message it looks for an XRO to see if 


exclusions are required. If the PCE finds more than one XRO, it MUST 
use the first one in the message and MUST ignore subsequent 
instances. 


If the PCE does not recognize the XRO, it MUST return a PCErr message 
with Error-Type "Unknown Object" as described in [RFC5440]. 


If the PCE is unwilling or unable to process the XRO, it MUST return 


a PCErr message with the Error-Type "Not supported object" and follow 
the relevant procedures described in [RFC5440]. 
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If the PCE processes the XRO and attempts to compute a path, it MUST 
adhere to the requested exclusions as expressed in the XRO. That is, 
the returned path MUST NOT include any resources encoded with the 
X-bit clear, and SHOULD NOT include any with the X-bit set unless 
alternate paths that match the other constraints expressed in the 
PCReq are unavailable. 


When a PCE returns a path in a PCRep, it MAY also supply an XRO. An 
XRO in a PCRep message with the NO-PATH object indicates that the set 
of elements of the original XRO prevented the PCE from finding a 
path. On the other hand, if an XRO is present in a PCRep message 
without a NO-PATH object, the PCC SHOULD apply the contents using the 
same rules as in [RFC4874] and the PCC or a corresponding LSR SHOULD 
signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs 
should apply. This may be particularly useful in per-domain path 
computation scenarios [RFC5152]. 


2.2. Explicit Route Exclusion 
2.2.1. Definition 


Explicit Route Exclusion defines network elements that must not or 
should not be used on the path between two abstract nodes or 
resources explicitly indicated in the Include Route Object (IRO) 
[RFC5440]. This information is encoded by defining a new subobject 
for the IRO. 


The new IRO subobject, the Explicit Exclusion Route subobject (EXRS), 
has type 33 (see Section 4). The EXRS contains one or more 
subobjects in its own right. An EXRS MUST NOT be sent with no 
subobjects, and if received with no subobjects, MUST be ignored. 


The format of the EXRS is as follows: 


0 1 2 3 

Q0 1.2 3 4b we Y 8.9- 0. 1 23,4 5 OP 8? 90 Oi 1-2 3.4 5-6 .7.:8-9-0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 
|L] Type | Length | Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 
| | 


// One or more EXRS subobjects / / 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
L 


MUST be set to zero on transmission and MUST be ignored on 
receipt. 
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Reserved 
MUST be set to zero on transmission and SHOULD be ignored on 
receipt. 


The EXRS subobject may carry any of the subobjects defined for 
inclusion in the XRO by this document or by future documents. The 
meanings of the fields of the XRO subobjects are unchanged when the 
subobjects are included in an EXRS, except that scope of the 
exclusion is limited to the single hop between the previous and 
subsequent elements in the IRO. 


2.2.2. Processing Rules 


A PCC that supplies a partial explicit route to a PCE in an IRO MAY 
also specify explicit exclusions by including one or more EXRSs in 
the IRO. 


If a PCE that does not support the use of EXRS receives an IRO in a 
PCReq message that contains an EXRS, it will respond according to the 
rules for a malformed object as described in [RFC5440]. The PCE MAY 
also include the IRO in the PCErr to indicate in which case the IRO 
SHOULD be terminated immediately after the unrecognized EXRS. 


If a PCE that supports the EXRS in an IRO parses an IRO and 
encounters an EXRS that contains a subobject that it does not support 
or recognize, it MUST act according to the setting of the X-bit in 
the subobject. If the X-bit is clear, the PCE MUST respond with a 
PCErr with Error-Type "Unrecognized EXRS subobject" and set the 
Error-Value to the EXRS subobject type code (see Section 4). If the 
X-bit is set, the PCE MAY respond with a PCErr as already stated or 
MAY ignore the EXRS subobject: this choice is a local policy 
decision. 


If a PCE parses an IRO and encounters an EXRS subobject that it 
recognizes, it MUST act according to the requirements expressed in 
the subobject. That is, if the X-bit is clear, the PCE MUST NOT 
produce a path that includes any resource identified by the EXRS 
subobject in the path between the previous abstract node in the IRO 
and the next abstract node in the IRO. If the X-bit is set, the PCE 
SHOULD NOT produce a path that includes any resource identified by 
the EXRS subobject in the path between the previous abstract node in 
the IRO and the next abstract node in the IRO unless it is not 
possible to construct a path that avoids that resource while still 
complying with the other constraints expressed in the PCReq message. 
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A successful path computation reported in a PCRep message MUST 
include an ERO to specify the path that has been computed as 
specified in [RFC5440]. That ERO MAY contain specific route 
exclusions using the EXRS as specified in [RFC4874]. 


If the path computation fails and a PCErr is returned with a NO-PATH 
object, the PCE MAY include an IRO to report the hops that could not 
be complied with as described in [RFC5440], and that IRO MAY include 
EXRSs. 


3. Exclude Route with Confidentiality 
3.1. Exclude Route Object (XRO) Carrying Path-Key 
3.1.1. Definition 


In PCE-based inter-domain diverse path computation, an XRO may be 
used to find a backup (secondary) path. A sequential path 
computation approach may be applied for this purpose, where a working 
(primary) path route is computed first and a backup path route that 
must be a node/link/SRLG disjoint route from the working path is then 
computed [RFC5298]. Backward Recursive Path Computation (BRPC) may 
be used for inter-domain path computation [RFC5441]. 


In some cases of inter-domain computation (e.g., where domains are 
administered by different service providers), confidentiality must be 
kept. For primary path computation, to preserve confidentiality, 
instead of explicitly expressing the computed route, Path-Key 
Subobjects (PKSs) [RFC5520] are carried in the Explicit Route Object 
(ERO) in the PCRep Message. 


Therefore, during inter-domain diverse path computation, it may be 
necessary to request diversity from a path that is not fully known 


and where a segment of the path is represented by a PKS. This means 
that a PKS may be present as a subobject of the XRO on a PCReq 
message. 


The format and definition of PKS when it appears as an XRO subobject 
are as defined in [RFC5520], except for the definition of the L bit. 
The L bit of the PKS subobject in the XRO MUST be ignored. 
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3.1.2. Processing Rules 


Consider that BRPC is applied for both working and backup path 
computation in a sequential manner. First, PCC requests PCE for the 
computation of a working path. After BRPC processing has completed, 
the PCC receives the results of the working-path computation 
expressed in an ERO in a PCRep message. The ERO may include PKSs if 
certain segments of the path are to be kept confidential. 


For backup path computation, when the PCC constructs a PCReq Message, 
it includes the entire working-path in the XRO so that the computed 
path is node/link disjoint from the working path. The XRO may also 
include SRLGs to ensure SRLG diversity from the working path. If the 
working path ERO includes PKS subobjects, these are also included in 
the XRO to allow the PCE to ensure diversity. 


A set of PCEs for backup path computation may be the same as ones for 
working path computation, or they may be different. 


— Identical PCEs 


In the case where the same PCEs are used for both path 
computations, the processing is as follows. During the process of 
BRPC for backup path computation, a PCE may encounter a PKS as it 
processes the XRO when it creates a virtual path tree (VPT) in its 
own domain. The PCE retrieves the PCE-ID from the PKS, recognizes 
itself, and converts the PKS into a set of XRO subobjects that it 
uses for the local calculation to create the VPT. The XRO 
subobjects created in this way MUST NOT be shared with other PCEs. 
Other operations are the same as BRPC. 


— Different PCEs 


In the case where a set of PCEs for backup path computation is 
different from the ones used for working path computation, the 
processing is as follows. If a PCE encounters a PKS in an XRO 
when it is creating a virtual path tree in its own domain, the PCE 
retrieves the PCE-ID from the PKS and sends a PCReq message to the 
identified PCE to expand the PKS. The PCE computing the VPT 
treats the path segment in the response as a set of XRO subobjects 
in performing its path computation. The XRO subobjects determined 
in this way MUST NOT be shared with other PCEs. 
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4. IANA Considerations 
4.1. PCEP Objects 


The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 
IANA has made the following allocations from this registry. 


Object Name Reference 
Class 
17 XRO [RFC5521] 


Object-Type 
1: Route exclusion 


This object should be registered as being allowed to carry the 
following subobjects: 


Subobject Type Reference 
1 IPv4 prefix [RFC3209] 
2 IPv6 prefix [RFC3209] 
4 Unnumbered Interface ID [RFC3477] 
32 Autonomous system number [RFC3209] 
34  SRLG [RFC4874] 
64 Path-Key with 32-bit PCE ID [RFC5520] 
65 Path-Key with 128-bit PCE ID [RFC5520] 


4.2. New Subobject for the Include Route Object 


The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 
with an entry for the Include Route Object (IRO). 


IANA added a further subobject that can be carried in the IRO as 


follows: 
Subobject Type Reference 
33 Explicit Exclusion Route subobject (EXRS) [RFC4874] 


4.3. Error Object Field Values 


The "PCEP Parameters" registry contains a subregistry "Error Types 


and Values". IANA made the following allocations from this 
subregistry. 

Error 

Type Meaning Reference 
11 Unrecognized EXRS subobject [RFC5521] 
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4.4. Exclude Route Flags 
IANA created a subregistry of the "PCEP Parameters" for the bits 
carried in the Flags field of the Exclude Route Object (XRO). The 
subregistry is called "XRO Flag Field". 


New bits may be allocated only by an IETF Consensus action. 


The field contains 16 bits numbered from bit 0 as the most 
significant bit. 


Bit Name Description Reference 
15 F-bit Fail [RFC5221] 
5. Manageability Considerations 


A MIB module for management of the PCEP is being specified in a 


Separate document [PCEP-MIB]. That MIB module allows examination of 
individual PCEP messages, in particular requests, responses and 
errors. 


The MIB module MUST be extended to include the ability to view the 
route exclusion extensions defined in this document. 


Several local policy decisions should be made at the PCE. Firstly, 
the exact behavior with regard to desired exclusions must be 
available for examination by an operator and may be configurable. 
Second, the behavior on receipt of an unrecognized XRO or EXRS 
subobject with the X-bit set should be configurable and must be 
available for inspection. The inspection and control of these local 
policy choices may be part of the PCEP MIB module. 


6. Security Considerations 


The new exclude route mechanisms defined in this document allow finer 
and more specific control of the path computed by a PCE. Such 
control increases the risk if a PCEP message is intercepted, 
modified, or spoofed because it allows the attacker to exert control 
over the path that the PCE will compute or to make the path 
computation impossible. Therefore, the security techniques described 
in [RFC5440] are considered more important. 


Note, however, that the route exclusion mechanisms also provide the 


operator with the ability to route around vulnerable parts of the 
network and may be used to increase overall network security. 
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